home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part1 / 735 < prev    next >
Encoding:
Text File  |  1996-08-06  |  3.9 KB  |  165 lines
  1. Newsgroups: comp.lang.c++
  2. Path: hpwisf1.han.federal.unisys.com!usenet
  3. From: Bill Kaelin <kaelin@federal.unisys.com>
  4. Subject: Please Explain this manipulator behavior
  5. Content-Type: text/plain; charset=us-ascii
  6. Message-ID: <30EEBF72.4DDD565A@federal.unisys.com>
  7. Sender: usenet@Federal.Unisys.COM
  8. Nntp-Posting-Host: h122-70.mcln.federal.unisys.com
  9. Content-Transfer-Encoding: 7bit
  10. Cc: mcintire@federal.unisys.com
  11. Organization: Unisys Federal Systems
  12. Mime-Version: 1.0
  13. Date: Sat, 6 Jan 1996 18:29:06 GMT
  14. X-Mailer: Mozilla 2.0b4 (X11; I; Linux 1.2.13 i486)
  15.  
  16. Hi,
  17.  
  18. I've recently been investigating manipulators and have come across
  19. behavior that I don't understand.  The only way to convey the problem is
  20. by example.  I've included the Makefile, main.cc, My_Class_c.hh and
  21. My_Class_c.cc.  Please take a moment to look at these.
  22.  
  23. ********
  24. Makefile
  25. ********
  26. CFLAGS          =-g
  27. LDFLAGS         =
  28. RM              =rm
  29. TARGET_EXECUTABLE=main
  30.  
  31. SRCS    = \
  32.                 My_Class_c.cc   \
  33.                 main.cc
  34.  
  35. OBJS            =$(SRCS:.cc=.o)
  36.  
  37.  
  38. $(TARGET_EXECUTABLE): $(OBJS)
  39.         $(CC) $(LDFLAGS) -o $(TARGET_EXECUTABLE) $(OBJS)
  40.  
  41. clean:
  42.         $(RM) -f core $(OBJS) $(TARGET_EXECUTABLE)
  43.  
  44. .SUFFIXES:
  45. .SUFFIXES: .o .cc .hh
  46. .cc.o:
  47.         $(CC) -c $(CFLAGS) $<
  48.  
  49.  
  50. ********
  51. main.cc
  52. ********
  53. #include "My_Class_c.hh"
  54. #include <iomanip.h>
  55.  
  56. int main(void)
  57. {
  58. My_Class_c My_Class;
  59.  
  60. unsigned int my_uint = 0x00410040;
  61.  
  62. cout.fill('0');
  63. cout<<"my_uint is set to: 0x"<<hex<<setw(12)<<my_uint<<"."<<endl;
  64.  
  65. return(0);
  66. }
  67.  
  68. ********
  69. My_Class_c.hh
  70. ********
  71. #if    !defined(_My_Class_c_HH)
  72. #define         _My_Class_c_HH
  73.  
  74. #include <iostream.h>
  75.  
  76. class My_Class_c : public ostream {
  77. //class My_Class_c {
  78.     public:
  79.         My_Class_c();
  80.         ~My_Class_c();
  81. };
  82.  
  83. #endif //       _My_Class_c_HH
  84.  
  85.  
  86. ********
  87. My_Class_c.cc
  88. ********
  89. #include "My_Class_c.hh"
  90. #include <iomanip.h>
  91.  
  92. //
  93. // Body for Function: My_Class_c
  94. //
  95. My_Class_c::My_Class_c()
  96. {
  97. unsigned int my_uint1 = 0x0cc00040;
  98.  
  99. cout.fill('0');
  100. cout<<"my_uint1 is set to: 0x"<<hex<<setw(12)<<my_uint1<<"."<<endl;
  101. }
  102.  
  103.  
  104. //
  105. // Body for Function: ~Info_c
  106. //
  107. My_Class_c::~My_Class_c()
  108. {
  109. }
  110.  
  111. ************************************************************************
  112.  
  113. As coded, the unexpected output is:
  114.  
  115. $ ./main
  116. my_uint1 is set to: 0x64000213909568.
  117. my_uint is set to: 0x000000410040.
  118. $
  119.  
  120. If change the class definintion in My_Class_c.hh, so that My_Class_c
  121. does not inherit from ostream, e.g. change the two lines in
  122. My_Class_c.hh to:
  123.  
  124. //class My_Class_c : public ostream {
  125. class My_Class_c {
  126.  
  127. Then the output is:
  128.  
  129. $ ./main
  130. my_uint1 is set to: 0x00000cc00040.
  131. my_uint is set to: 0x000000410040.
  132. $
  133.  
  134.  
  135. Therefore, somehow by inheriting from ostream, the "hex" manipulator no
  136. longer modifies the output to be in hex.  Instead a mysterious "64" is
  137. output and the following value is output in decimal instead of hex.
  138.  
  139. If I don't inherit from ostream, then the output is as expected.  Note
  140. that the setw manipulator works as expected in both cases.
  141.  
  142. I've compiled and executed this example with 4 different C++ compilers
  143. and all exhibit this unusual behavior (Sun CC, Centerline CC, dynix/ptx
  144. CC, and gnu g++ under Linux).
  145.  
  146. I've done some sleuthing into this problem.  Namely, looking in the
  147. iostream.h file, there is an enum which has "hex" as one of its members.
  148. Interestingly, this hex enum has the value of 0x0040.  In decimal this
  149. is 64!  Therefore, it is my belief that by inheriting from ostream,
  150. "hex" takes on the value of 64(decimal) which is output instead of being
  151. the manipulator to modify the stream to output in hex.
  152.  
  153. Is this the appropriate behavior for C++??  If this is true, how can one
  154. inherit from ostream and still output hexadecimal values?
  155.  
  156. Please reply with e-mail.
  157.  
  158. Thanks in advance.
  159.  
  160.    --------------------------------------------------------------
  161.    Bill Kaelin (kaelin@federal.unisys.com)  Unisys Federal Systems
  162.    (703) 620-7062 (USA)                     12010 Sunrise Valley Drive
  163.    (703) 620-7833 (USA FAX)                 Reston, VA 22091-3498
  164.    Opinions are my own not UFS's.
  165.